Processing critical information relies on the security of the computing platform. Typical security goals are to prevent such critical information from leaking beyond the realm of machines that are trusted by the user or to prevent corrupted machines from impacting the integrity of a computation. External verification of platform integrity enables a machine to verify that another machine meets certain security requirements. This is useful, for example, when a grid server wants to assure that a grid node is untampered before delegating a grid process to it.
In the following example two computers or machines A and B interact over a network. In the example machine A can make certain statements about its own state, e.g. “I am in status access” or “My software . . . is in status x”, or deliver a hash or checksum of this status (h(x)), or certain properties, e.g. “I am running version . . . of Linux”. Machine A can send these statements to machine B, but why should machine B trust machine A with respect to the correctness of these statements? If machine A is corrupted by a hacker, it could make arbitrary claims about itself.
Therefore, it is desired to implement a proving method with which machine B can verify whether the statements made by machine A are correct. The embodiment of such a proving method is shown in FIG. 1. In the following, machine A is called verified machine or the prover and machine B the verifier. All solutions to this problem assume that there is a piece of hardware, called trusted platform module TPM, which cannot be compromised, and which can make reliable statements about the rest of the system A. Specifically, the industry consortium Trusted Computing Group (TCG) has specified the trusted platform module TPM, which can compute a checksum of the system configuration of machine A, wherein the checksum can be computed for a system configuration in which all or only a part of the software is running on machine A. In a further step the computed checksum is signed, and afterwards send off to the verifier B. The corresponding protocol is shown in FIG. 2.
The Trusted Computing Group is an IT industry consortium which has developed a specification of a small, low-cost commodity hardware module, called trusted platform module (TPM). The TPM can serve as a root of trust in remote (and local) platform verification. The base TCG model of this configuration verification process, called binary attestation, aims at measuring all executed code. Therefore, each measured piece of software stores metrics of a sub-component into the TPM before executing it, wherein the metrics are hash values of the configuration's components. The metrics are bootstrapped by the basic input output system (BIOS) that is trusted by default and that is measuring and storing the boot loader. The chain of trust can then be extended to the operating system components and to the applications and their configuration files. Once the executables are measured into the TPM, the TPM can reliably attest to the metrics of the executed components by signing the metrics with a TPM-protected key. The signed metrics, also called integrity metrics, can then be transmitted to a verifying machine. This verifier machine, or in short verifier, can decide whether to consider the verified machine trustworthy enough to involve it in a subsequent computation. As will be elaborated hereinafter, this straightforward approach of binary attestation lacks privacy. The main reason therefore is that the whole configuration is transmitted.
Hereinafter, the binary attestation and verification is explained. The ability of the TPM reliably to report on the verified platform's computing environment follows from the TPM-enabled measurement and reporting. The description in the following paragraphs focuses on a PC-platform. Nevertheless, the TPM can be implemented in any platform or computing device, e.g. mobile phone, PDA, notebook, etc. The measurement and storage of integrity metrics is started by the BIOS boot block (a special part of the BIOS which is believed to be untampered) measuring itself and storing the measurements in a TPM PCR (platform configuration register) before passing control to the BIOS. In the same way, the BIOS then measures option ROMs and the boot loader and records these measurements in a TPM PCR before passing control to the boot loader. The process continues as the boot loader measures and stores integrity metrics of the operating system (OS) before executing it. The OS in turn measures and stores integrity metrics of additionally loaded OS components before they are executed. If support by the OS is provided, applications can also be measured before being executed. The measurement and reporting processes are depicted in a simplified manner in FIG. 2, in which H represents the cryptographic hash function SHA-1. During initialization, various platform configuration registers PCRx as well as a configuration log file log (stored on the platform) are initialized. This log file log keeps track of additional information such as descriptions or file paths of loaded components. Its integrity needs not to be explicitly protected by the TPM. During subsequent measurement of components, this log file log is extended, while metrics (hash values) of the executables are stored in the TPM using the tpm_extend method replacing the contents of the appropriate platform configuration register PCRx with the hash of the old contents and the new metrics, wherein metrics of loaded components are reliably stored in the TPM. When a remote verifier B wants to assess the security of the verified platform A, the verifier B sends a challenge c to the platform A. The platform A uses this challenge c to query with a tpm_quote command the TPM for the value of the platform configuration registers PCR. The TPM responds with a signed message qu=signAJK(), c) containing the PCR values and the challenge c. The platform A returns this signed quote qu to the challenger (verifier B) together with information from the log file log needed by the verifier B to reconstruct the verified platform's configuration. The verifier B can then decide whether this configuration is acceptable. The key used for signing the quote is an attestation identity key AIK of the TPM. As a TPM may have multiple attestation identity keys, the key or its identifier has to be specified in the tpm_quote request. An attestation identity key AIK is bound to a specific TPM. Its public part is certified in an attestation identity key certificate by a privacy-certification authority as belonging to a valid TPM. The verifier of a quote signed with a correctly certified AIK believes that the quote was produced by a valid TPM, more specifically, by the unique TPM owning that AIK. This belief is based on the assumption that the TPM is not easily subject to hardware attacks and that effective revocation mechanisms are in place dealing with compromised keys.
Note that the above measurement process does not prohibit execution of untrusted code, it only guarantees that the measurement of such code will be securely stored in the TPM. Thus, if malicious code is executed, the integrity of the platform A may be destroyed. However, the presence of an untrusted or simply unknown component will be reflected by the TPM quotes not matching the correct or expected values.
Further information about the Trusted Computing Group and the trusted platform module can be found in The Trusted Computing Group, Main specification version 1.1b, 2003, which is available from the Trusted Computing group.
The trusted platform module TPM also supports trusted booting, which means that the prover A can go through a sequence of steps. In each step a new component is loaded e.g., first the boot loader, then the operating system, and then an application. The TPM ensures that each step succeeds only if all previous steps succeeded. Via trusted booting one can ensure that the prover A boots into a known, well-defined state, with certain properties.
A related, theoretically well investigated feature is secure booting. The difference to trusted booting is that a system with secure booting either boots a specific, pre-defined system or does not boot at all, while a system with trusted booting can boot any system, but certain data are accessible only if it boots into a pre-defined system. The details of how a secure boot process can be carried out can be looked up in B. Yee, “Using secure coprocessors”, Technical Report CMU-CS-94-149, Carnegie Mellon University School of Computer Science, May 1994.
The above mentioned TCG specifications define mechanisms for a TPM-enabled platform to reliably report its current hardware and software configuration to a local or remote challenger. This binary attestation, based on measurements of binary executables, firstly requires that the platform builds a chain of trust from the hardware up to the operating system and potentially, including applications by measuring integrity metrics of modules and storing them in the TPM, and secondly requires that the TPM is able to report on these integrity metrics in an authenticated way. A verifier obtaining such authenticated integrity metrics can then match them against the values of a known configuration and decide whether the verified machine meets the security requirements or not. But with that, the privacy of the verified machine is violated, because with this approach the prover needs to reveal its configuration. The verifier gets information about the configuration of the verified machine, e.g. which operating system and which applications are running on the verified machine. This will not be acceptable to consumer since it raises substantial privacy concerns.